In #5099, I found such always non-null warning was too aggressive, especially when the nullability can't be fully expressed.
The practice of .NET Runtime is that extra null check won't harm except extremely hot path.
How do you think about turning off the Resharper warning instead?

Ah, I didn't notice this was only a resharper warning. That's a good point.

The only disable ReSharper offers is a global disable, which we definitely don't want and removes half the purpose of NRT (to simplify and remove null checks).

This is a very extreme edge case for us, because we can usually assume the dependency is present in practically all user cases except Dispose(). Any other cases are very unlikely to be hit - e.g. we can't assume dependencies are present in CreateChildDependencies() either but we haven't hit this case yet across the entire osu! game.

The only alternative I can provide is to use ! everywhere, but that doesn't seem to be getting much traction within the team/contributors.

The only alternative I can provide is to use ! everywhere, but that doesn't seem to be getting much traction within the team/contributors.

Assuming this means marking dependencies as nullable and using ! everywhere, and yeah I'm not sure about that approach, since a non-null dependency can only ever be null when accessed either before load or on disposal.

But I guess that can also become a major problem at the same time because it's easy to miss such cases during review and blow up anything by mistake...

I don't have a strong opinion on this to be honest, and having IsNull/IsNotNull that should only ever be used when not able to do != null feels off... I guess I could live with it if it's explicitly documented that the method is only meant to be used for such places, and never used anywhere else.

My two cents:

• Agree that disabling "redundant non-null" checks everywhere defeats most of the point of nullability annotations. Yes it is awkward in some cases, but it's better than the alternative of allowing anything and everything to be null-checked even if there is no conceivable way that it can ever be null. It's a code quality concern for me.
• I personally find the ! operator to be sloppy - a "shut the compiler up" measure at best. Therefore, while it's unavoidable in some cases, I argue that its scope of use should be as narrow as possible. I would detest needing to sprinkle an exclamation point upon every single access to a DI'd component.

In light of both views I'm more than fine with these existing, except maybe I'd add a note in the xmldoc (probably in a remarks section) as to why they exist and what the intended usage is.